Automated connection control in optical or connection-oriented networks operates currently with fully distributed control, where requests for connections are made from the source node, either triggered by a client request (switched connection (SC)) or by management system (soft permanent connection (SPC)). A client request can utilize a standard user-network interface protocol such as have been defined in the Internet Engineering Task Force (IETF) or in the Optical Internetworking Forum (OIF), while management system interfaces are typically highly equipment dependent, as the management interface needs to be tailored to manage each device's unique set of characteristics.
Path Computation Elements (PCEs) are described, for example, in RFC 4655 “A Path Computation Element (PCE)-Based Architecture,” (August 2006), the contents of which are incorporated by reference herein. This includes another standardized interface that has been defined for path computation, where the source node does not do its own path computation upon receiving a connection request (either SC or SPC) but makes a query to the centralized PCE. The Path Computation Client (PCC) requests a path to a specified destination with some constraints such as connection type or bandwidth, and the PCE responds with a list of nodes and links to be used, then the PCC creates the specified path using signaling. PCCs are also described, for example, in RFC 4655. The PCE was originally defined to be stateless, that is, having no memory retained after a path query has been received and responded to. A new extension to PCE now allows the PCE to retain state information, and in some cases affect the state of an established connection, for which the source node has previously delegated control to the PCE. This involves synchronization of the connection state between the PCC and PCE so that the PCE has an initial record of the connection state, then optionally delegation of state control from the PCC to the PCE, and then state updates from either side, from the PCC to reflect any events such as failures and from the PCE to reflect changes that it wants to make to the connection such as rerouting or deleting.
Finally work on Software Defined Networks (SDN) calls for the ability to centrally program provisioning of forwarding in the network in order for more flexible and precise control over network resources to support new services. OpenFlow (www.openflow.org) is an implementation of this which requires a special OpenFlow interface from the controller to each switch in the network in order to provision the forwarding table at each switch along a connection path in order to instantiate the forwarding behavior needed for the connection. OpenFlow is described, for example, in the OpenFlow Switch Speciation, Version 1.1.0 (February 2011), the contents of which are incorporated by reference herein.
In the current state of the art, using distributed control plane, the establishment of connections is typically disjointed, as for SC connections there is no central coordination but each request is responded to separately by a receiving source node, while for SPC connections coordination of multiple connections is only possible within a limited span of control of a single management system, and does not easily expand to handle multiple different vendors' equipment or even multiple types of equipment made by a single vendor, which may use different management systems.
PCE allows centralization of path computation, but in its stateless mode the control of the connections themselves is still distributed to the source node, while in stateful mode control can only be exerted by the PCE after the connection has been established and the source node has delegated control to the PCE. The PCE does not have any way to exert control on the initial establishment of the connection, and must rely on the source node to first request path computation and secondly delegate control of the connection to the PCE. The source node can take back control of the connection at any time. Also, OpenFlow/SDN fully centralized control does not take advantage of existing distributed intelligence in the switch that provides greater efficiency and reliability than fully centralized control.